Classes define the applicability, or scope, of a rule instance. Knowledge of the different layers of classes and their inheritance relationships is important as you develop applications.
Framework classes define a common work-processing foundation that you extend and modify as implementation applications for an organization, division, or organization unit. Framework classes belong to the framework layer.
For example, the MyCo enterprise makes auto loans and has an auto loan framework application that contains all of the assets needed for the basic auto loan process. Then, the MyCo enterprise develops two implementations built on the auto loan framework to meet the specific requirements of its two divisions: a commercial business line and a personal line.
Using the New Application wizard, you can build a new implementation application and its implementation classes on a framework application. You can reuse some or all of the case types and data types of the framework. From the new implementation application, you can use the Designer Studio landing pages, explorers, rule forms, and reports to reuse many of the rules and data objects inherited from the built-on framework layer. For example, while developing a process, you can select specifications or processes in a framework ruleset for reuse or customization in the current application.
When you build an implementation application, you can also create a reusable framework application built on the same framework. You can extend the framework so that it is used by other implementations that you might create later. As a best practice, reuse framework rules and create only specialized rules in your implementation application. For example, use report definitions in the framework classes that run with the corresponding implementation classes.
Note: Framework classes are different from Strategic Applications, which are starter applications for specific industries or lines of business.
Implementation classes define the extension, reuse, and specialization of assets in a framework layer to meet the business requirements of an organization, division, or organization unit. For example, you can build two division-level implementations—business auto loan and personal auto loan—on an organization's auto loan framework layer.
Implementation classes belong to the implementation layer. Typically, cases that are related to application processes are instances of case type classes that belong only to the implementation layer.
Organization classes contain enterprise-wide data assets and assets that must be reused for business logic. Data assets include classes and rules for data stored in the system, and classes and rules for access to data in external systems by using connectors. Business logic assets include standard properties, decision tables, and service-level agreements.
For example, the MyCo enterprise might want to reuse, on an enterprise-wide basis, the property for employee serial number. By reusing this property, the various applications across the enterprise that an employee uses can consistently rely on the same serial number property for the same employee.
Organization classes belong to the organizational layer. In most configurations, your implementation and framework layers inherit (by pattern inheritance) from organization classes.
Tip: To identify the inheritance relationships among these classes, you can right-click the class name in the Application Explorer and select the Inheritance option.